A traffic firewall or fence (TF) may regulate the types of traffic entering and/or exiting a public and/or private network (e.g., a Layer 1 optical transport network, a Layer 3 Internet Protocol (IP) network, etc.). For example, TFs may exercise control over incoming and/or outgoing traffic to or from restricted portions of a network. Many public carriers have relied upon network management systems or operation support systems (NMS/OSS) to perform TF functions. NMS/OSS may configure a network to enforce a set of rules or functions regarding traffic handled by certain portions (e.g., restricted portions) of the network. Examples of such rules may include: (1) limiting entrance of traffic of certain classes to a portion of the network; (2) preventing traffic of certain classes from exiting a portion of the network; (3) preventing traffic of certain classes from using a portion of the network as a transit route; and/or (4) isolating a portion of the network from the remaining network but permitting communication within the isolated portion.
The NMS/OSS-based approach has several drawbacks. For example, NMS/OSS may be labor intensive and prone to errors because circuit design rules may have to be manually changed and/or routing tables used for end-to-end path calculations may have to be updated. Existing NMS/OSS functions may be closely tied to a transport technology it manages and may be vendor specific. In large networks (e.g., a public carrier network), numerous technologies may be deployed on different layers of the network, and multiple vendors may be involved. Each NMS/OSS may use different procedures to create TFs, and multiplicity of NMS/OSS may further complicate management of TFs, especially if the NMS/OSS spreads across vendor domains and/or network layers.
Lack of standard interfaces between NMS/OSS and network devices, as well as a standard procedure to construct TFs, may make it very difficult to streamline and/or automate TF-related procedures. Furthermore, the current NMS/OSS-based procedure will be phased out by the deployment of an intelligent control plane (CP) in next generation transport networks (NG-TN) (e.g., next generation optical transport networks (NG-OTN)). In the near future, NMS/OSS will no longer play an active role in designing and/or routing end-to-end circuits. The CP will take over that function, along with the responsibility to create and/or manage TF functions. However, current CP standards and industry-wide implementation agreements (IAs) do not support TF functions on standard CP network interfaces.